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METHOD AND APPARATUS FOR ROUTING INFORMATION IN SATELLITE 



COMMUNICATION NETWORKS 



BACKGROUND OF THE INVENTION 

1 1 . Technical Field 

2 The present invention pertains to satellite communication networks. In particular, the 

3 present invention pertains to low orbit satellite communication networks that utilize apriori 

4 knowledge of network topology (e.g., as a function of time or satellite geographical location) 

5 to enhance routing efficiency and significantly increase overall network performance. 

6 2. Discussion of Related Art 

7 Dynamic routing in a single Autonomous System of an Internet Protocol (IP) based 

8 communication network is typically accomplished by employing an Interior Gateway 

9 Protocol (IGP), such as the Open Shortest Path First (OSPF) routing protocol. The OSPF 

10 protocol is basically an internetworking or gateway protocol facilitating communications 

1 1 with external networks. For examples of implementation of the OSPF Protocol, reference is 

12 made to RFC 1583, Moy, "OSPF Version 2," March 1994, the disclosure of which is 

13 incorporated herein by reference in its entirety. 

14 Routing is accomplished in the OSPF protocol by each network node having a routing 

15 database containing information related to network topology (e.g., links between network 

16 nodes). The routing database is utilized by each node to determine a path for transmitting a 

17 message to a destination site. The routing or path information is typically stored in a routing 

18 table. The routing databases are updated by exchanging link-state advertisement (LSA) 

19 packets between neighboring nodes. These packets generally include information related to 

20 current links of network nodes and are typically transferred periodically and/or in the event of 

21 a modification to the network topology. The OSPF protocol designates a particular router to 

22 flood LSA packets to neighbors in broadcast type networks, while LSA packets are 

23 transmitted via point-to-point and/or broadcast packets within non-broadcast type networks. 

24 Thus, the OSPF protocol is capable of ascertaining the topology of an Internet Protocol 

25 communication network and determining routes to be used by the Internet Protocol. 

26 The OSPF protocol may further detect disabled communication links via periodic 

1 



1 transmission and reception of neighbor discovery and maintenance or "Hello" type packets 

2 between network nodes. These packets are periodically transmitted by each node to discover 

3 neighboring nodes and to ensure communications between that node and the neighboring 

4 nodes. In addition, the OSPF protocol may determine alternative routes for current routes 

5 that utilize disabled links and are no longer viable. However, the OSPF routing protocol 

6 suffers from several disadvantages. In particular, the protocol takes a finite time interval to 

7 detect and repair a broken or disabled route. Although this is unavoidable in cases where the 

8 route becomes disabled due to an unforeseen event, protocol efficiency is less than optimal 

9 when apriori knowledge is available concerning network topology changes that affect 

10 viability of routes. In this case, protocol efficiency may be enhanced by determining 

1 1 alternative routes prior to a network topology change. 

12 In an attempt to accommodate network topology changes, the related art provides 

13 various systems that determine alternative routes based on modifications to the network 

14 topology. For example, U.S. Patent No. 5,365,520 (Wang et al) discloses dynamic signal 

15 routing. Data packets are delivered through a constellation of nodes or satellites to a 

16 termination unit. The node where a packet leaves the constellation is a terminal node. Each 

17 packet includes a routing code. When a node receives a packet, the node examines the 

18 routing code to determine if that node might be a terminal node for that packet. A table look 

19 up operation is performed using the routing code as an index to a routing table. The table 

20 identifies a link to use in routing the packet to a neighbor node. A number of different tables 

21 are used for each orbit, where the tables may be generated to track the movement of nodes 

22 over space regions. The packet is also examined to verify compatibility between packet type 

23 and a selected link. When a node concludes that the node might be a terminal node, the node 

24 evaluates a channel identifier to determine if the node is currently serving the party to whom 

25 the packet is directed. 

26 U.S. Patent No. 5,999,797 (Zancho et al) discloses a method and apparatus for 

27 providing private global networks in a satellite communication system. The private networks 

28 between communication terminals are established within a satellite communication system. 

29 Each private network provides users a network of dedicated communication paths that have 

30 durations exceeding the duration of the particular call. A dedicated communication path is 

3 1 established by determining hand-off schedules for satellite-to-terminal links for both a source 

32 and destination terminal, and by determining satellite crosslink schedules necessary to 

33 maintain the dedicated path for a duration exceeding the particular call. 
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1 U.S. Patent No. 6,157,624 (Zancho) discloses a method and apparatus for linking 

2 terminals using private secondary service paths in a satellite communication system. The 

3 secondary paths between compatible or non-compatible communication terminals are 

4 established using terrestrial stations within a satellite communication system. Each 

5 secondary path provides users the ability to establish communication paths between 

6 compatible or non-compatible terminals. A secondary path is established using terrestrial 

7 stations that establish and maintain terrestrial-based links and satellite communication links. 

8 Terrestrial stations also perform frequency translating and data reformatting to allow non- 

9 compatible terminals to communicate with each other. Since the topology of a satellite 

10 communication system is constantly changing, maintenance of a secondary path involves 

11 satellite-to-terrestrial station hand-offs and establishment of different inter-satellite 

12 crosslinks. A prediction of system topology during the duration of the secondary path, or a 

13 portion thereof, is used to determine the satellite crosslinks. 

14 The related art systems suffer from several disadvantages. In particular, the Wang et 

15 al system generates a stream of look up tables for each orbit to determine routing with respect 

16 to topology changes, thereby requiring significant processing and increasing system 

17 complexity. The Zancho et al and Zancho systems determine crosslink schedules that are 

18 employed by satellites to control crosslink establishment and relinquishment. Thus, these 

19 systems are required to distribute the schedules among the satellites, thereby providing 

20 additional tasks and overhead for communications. Further, since these systems control the 

21 crosslinks in accordance with the distributed schedules, the link control may interfere with 

22 and degrade performance of communication protocols employed by the systems. 

23 The present invention basically overcomes the aforementioned problems by allowing 

24 the OSPF or other routing protocol to recompute routes prior to a known change in network 

25 topology. This is achieved by preventing the protocol neighbor discovery and maintenance 

26 or "Hello" type packets from being sent and received on a link that is about to become 

27 disabled, due to a change in network topology. The cessation of these packets causes a 

28 protocol "dead" timer to expire for the link, thereby causing the protocol to consider the link 

29 disabled and recalculate routes in accordance with that consideration. Thus, new routes are 

30 determined prior to any previous routes becoming invalid due to the disabled link. 
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1 OBJECTS AND SUMMARY OF THE INVENTION 

2 Accordingly, it is an object of the present invention to determine routes within a 

3 network in accordance with knowledge of known topology changes. 

4 It is another object of the present invention to recompute routes within a network 

5 prior to current routes becoming disabled due to changes in network topology. 

6 Yet another object of the present invention is to recompute routes within a network 

7 prior to current routes becoming disabled by establishing conditions within the network that 

8 cause a routing protocol to recompute those routes. 

9 Still another object of the present invention is to enable a routing protocol to 

10 recompute routes within a network prior to current routes becoming disabled by inhibiting 

1 1 transmission and reception of neighbor discovery and maintenance packets over links about 

12 to become disabled. 

13 The aforesaid objects may be achieved individually and/or in combination, and it is 

14 not intended that the present invention be construed as requiring two or more of the objects to 

15 be combined unless expressly required by the claims attached hereto. 

16 According to the present invention, a communication network utilizes apriori 

17 knowledge of topology changes to facilitate computations of routes and to ensure 

18 transmission and reception of information. The communication network includes one or 

19 more ground stations and a plurality of satellites, preferably low orbiting. The ground stations 

20 and satellites basically serve as network nodes. The satellites each include a router that is 

21 interconnected to other satellite routers via point-to-point radio crosslinks, while the ground 

22 stations each include a router interconnected to satellite routers via radio uplinks and 

23 downlinks. The routers typically employ the OSPF routing protocol to route information 

24 through the network. Since the network topology changes due to known movement of the 

25 satellites, the present invention causes the OSPF protocol to recompute routes prior to certain 

26 routes becoming disabled. This is accomplished by preventing transmission and reception of 

27 neighbor discovery and maintenance or "Hello" type packets over the link becoming disabled 

28 due to a topology change. The present invention utilizes knowledge of the known satellite 

29 movements and topology changes to inhibit transmission and reception of those packets prior 

30 to a route becoming disabled. Thus, new routes are determined by the protocol prior to the 

3 1 previous routes becoming disabled due to a topology change. 
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1 BRIEF DESCRIPTION OF THE DRAWINGS 

2 Fig. 1 is a diagrammatic illustration of an exemplary satellite communication network 

3 or system employed by the present invention. 

4 Fig. 2 is a block diagram of a router according to the present invention. 

5 Fig. 3 is a diagrammatic illustration of an exemplary satellite communication network 

6 employed by the present invention as represented by a simulation tool. 

7 Fig. 4 is a diagrammatic illustration of an exemplary model of a present invention 

8 router as represented by the simulation tool. 

9 Figs. 5A - 5C are graphical illustrations of throughput for the simulated satellite 

1 0 communication network of Fig. 3 . 

11 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

S!( 12 An exemplary satellite communication network employed by the present invention is 

Q 13 illustrated in Fig. 1. Specifically, the network includes a plurality of satellites 10, preferably 

Q 

nj 14 low orbiting, and one or more ground stations 12. The ground stations and satellites basically 

V~15 serve as network nodes to facilitate communications through the network. The network may 

fU 16 be utilized for various applications. For example, the satellites may collect and process 

17 information for transference to other satellites or a particular ground station via the 

l~ 18 communication network. Further, information may be transmitted between ground stations 

fy 19 via the satellites (e.g., for general communications). 

f=l 20 The satellites and ground station each include a router 14 (Fig. 2) that is 

H= 21 interconnected with other network routers via point-to-point radio crosslinks (e.g., between 

22 satellite routers) or radio uplinks and downlinks (e.g., between satellite and ground station 

23 routers). Each satellite 10 includes a plurality of crosslinks 16, 18 to communicate with other 

24 satellites. Crosslinks 16 (e.g., forward and aft crosslinks as viewed in Fig. 1) basically 

25 arrange the satellites in a ring topology and enable communication between a particular 

26 satellite and the immediately succeeding (e.g., forward crosslink) and preceding (e.g., aft 

27 crosslink) satellites within the ring topology. These links are usually always enabled during 

28 system operation. Crosslinks 18 (e.g., East- West crosslinks as viewed in Fig. 1) facilitate 

29 communications between satellites having a mutual line of sight (e.g., the geographical 

30 positions of the satellites with respect to the Earth enable the existence of communication 

31 paths between the satellites). In other words, the satellites are positioned such that the Earth 

32 or other satellites do not interfere with transmissions between satellites. These crosslinks are 
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1 enabled when the geographical location of satellites enable the satellites to have a line of 

2 sight with each other (e.g., enable existence of a communication path between the satellites). 

3 The satellites further include one or more radio downlinks 20 to ground station 12, while the 

4 ground station includes one or more uplinks 22 to satellites 10. Links 20, 22 are enabled 

5 when corresponding satellites are in position to have a line of sight (e.g., enable the existence 

6 of a communication path) with the ground station. 

7 The communication network employs a routing protocol to facilitate routing of 

8 information throughout the network. By way of example only, the network utilizes the Open 

9 Shortest Path First (OSPF) Internet Protocol (IP) to dynamically discover routes. However, 

10 the network may employ any conventional or other routing protocols. According to the 

11 OSPF protocol, each node (e.g., satellite and ground station) within the network maintains a 

12 routing database (not shown) including information enabling the node to determine an 

13 appropriate path for routing a message. The information contained within the node databases 

14 typically relates to links (e.g., crosslinks, uplinks and downlinks) between the various 

15 network nodes, while routing information is typically maintained within a routing table. The 

16 OSPF protocol is a link-state type routing protocol and provides for synchronization of node 

17 databases through transmission of link-state advertisement (LSA) type or database update 

18 packets to each network node. These packets are conventionally transmitted to each 

19 neighboring network node via plural point-to-point messages (e.g., messages from a source 

20 node to a specific destination network node) in response to modifications to the network 

21 facilitating changes in a node database. When a database update packet is received, a point- 

22 to-point OSPF type acknowledgment (ACK) packet is commonly transmitted to the source 

23 node from the destination node to indicate packet reception. The OSPF protocol may further 

24 detect disabled communication links via periodic transmission and reception of neighbor 

25 discovery and maintenance or "Hello" type packets between network nodes. These packets 

26 are periodically transmitted by each node to discover neighboring nodes and to ensure 

27 communications between that node and the neighboring nodes. In addition, the OSPF 

28 protocol may determine alternative routes for current routes that utilize disabled links and are 

29 no longer viable. 

30 The OSPF protocol is a link-state type protocol as described above and provides 

3 1 several advantages with respect to distance vector type protocols, such as RIP, where routers 

32 exchange vectors of distances of preferred paths to known destinations. For example, the 

33 OSPF protocol quickly discovers and disseminates information relating to disabled or broken 
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1 links throughout the network. Further, link-state protocols generally have a faster 

2 convergence time than distance vector protocols. Moreover, distance vector protocols 

3 encounter "The Count-to-infinity Problem", where these protocols react slowly to links 

4 becoming disabled. Although the conventional "Split Horizon" algorithm partially alleviates 

5 this problem, that algorithm provides several other disadvantages. These types of 

6 convergence problems are not encountered with link-state protocols. Since each router 

7 maintains a database of the complete network topology, information relating to a disabled 

8 link may be disseminated rapidly throughout the network. The routers recompute routing 

9 tables that reflect the updated topology database. Thus, a link-state routing protocol is better 

10 suited to topology dynamics than a distance vector protocol. Although link-state protocols 

11 usually include greater overhead, the overhead associated with the OSPF protocol is 

12 significantly less than network bandwidth as described below. 

13 The present invention basically utilizes the features of the OSPF routing protocol and 

14 apriori knowledge of network topology (e.g., as a function of time or satellite geographical 

15 location) to enhance routing performance. The network topology knowledge enables the 

16 OSPF protocol to adjust a routing table prior to links becoming disabled due to changing 

17 satellite positions. The routing table adjustment essentially prevents the Internet Protocol 

18 from routing data packets to disabled links, thereby avoiding loss of those data packets. 

19 A network router according to the present invention is illustrated in Fig. 2. Initially, 

20 each satellite 10 (Fig. 1) includes a router 14 to route data packets throughout the network 

21 and facilitate communications. Specifically, router 14 includes an application module 30, 

22 transport protocol modules 32 (e.g., TCP), 34 (e.g., UDP), Internet Protocol module 36, 

23 topology prediction function (TPF) module 38, OSPF module 40, packet filter module 42 

24 and ports 44, 46, 48, 50, 52 and 54. The various router modules or components are typically 

25 implemented by software modules executed on a router processor (not shown), however, the 

26 modules may be implemented by any software and/or hardware modules in any combinations 

27 thereof. 

28 The router ports are coupled to radio transceivers (not shown) within the satellites to 

29 enable communications over crosslinks 16, 18, downlinks 20 and uplinks 22. The 

30 transceivers typically encrypt, modulate and transmit signals from a particular satellite and 

31 further receive signals from other satellites or the ground station. Ports 48, 50 are typically 

32 associated with crosslinks 16 coupling the satellite to the immediately succeeding and 

33 preceding satellites within the ring topology. Ports 44, 46 are associated with crosslinks 18 
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1 coupling the satellite to another satellite within the line of sight, while port 52 is associated 

2 with downlinks 20 coupling the satellite to ground station 12. Port 54 is associated with 

3 uplinks 22 coupling the ground station to satellites 10. 

4 The ports are each coupled to IP module 36. This module basically implements the 

5 Internet Protocol and serves as a switch to direct outgoing data packets to the appropriate 

6 ports and to direct incoming data packets to the proper router module for processing. IP 

7 module 36 is further coupled to transport protocol modules 32, 34. These modules basically 

8 enable exchange of information between satellite or other applications over the network. 

9 Modules 32, 34 may be implemented by various transport protocols, but, by way of example 

10 only, are implemented by the Transmission Control Protocol (TCP) and the User Datagram 

1 1 Protocol (UDP), respectively. Application module 30 is coupled to the transport protocol 

12 modules and facilitates execution of particular router, satellite or other applications. Packet 

13 filter module 42 is coupled to IP module 36, with topology prediction function module 38 

14 and OSPF module 40 coupled to packet filter module 42. OSPF module 40 basically 

15 implements the OSPF routing protocol, while modules 38, 42 modify the OSPF protocol to 

1 6 perform routing in accordance with the present invention as described below. 

17 The ground station includes a router substantially similar to the router described 

1 8 above, except that the ground station router ports include ports 52, 54. The ports are coupled 

19 to radio transceivers (not shown) within the ground station to enable communications over 

20 downlinks 20 and uplinks 22. The transceiver typically encrypts, modulates and transmits 

21 signals from the ground station and receives signals from the satellites. 

22 Modules 38, 42 modify the OSPF protocol to perform routing in accordance with the 

23 present invention as indicated in Table I below. 
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Table I: Dynamic System Recovery with Assistance of TPF 



Time 


Module 


■• ■ • Events 


t-T 


OSPF 


The OSPF module receives a neighbor packet from one 
of its interfaces and starts the Dead Interval timer. 


t 


TPF 


The TPF module predicts that a link is about to go down 
and informs the Packet Filter module. 


t 


Packet Filter 


The Packet Filter module discards all the neighbor 
packets coming from or going to the interface or link that 
is predicted to go down. 


t-z + D 


OSPF 


The Dead Interval timer expires for the predicted link. 
OSPF starts to compute a new routing table and sends a 
Link State Update to its neighbors. 


t-r + D + T 


OSPF 


The OSPF Module finished the routing table calculations 
and passed the new routing table to the IP module. 


t + D + T 


Link 


The predicted link goes down. 


t + 2D + T 


TPF 


The TPF module informs the Packet Filter module to 
stop discarding the neighbor packets for the predicted 
link. 


t + 2D + T 


Packet Filter 


The Packet Filter stops discarding the neighbor packets 
for the predicted link. 



1 In particular, topology prediction module 38 determines, based on apriori knowledge of 

2 satellite locations, that a crosslink 16, 18, a downlink 20 or an uplink 22 is about to become 

3 disabled at a time, t. This time is subsequent the time, t - x, when the OSPF module received 

4 a neighbor discovery and maintenance packet from another satellite or the ground station and 

5 initiated a "Dead Interval" timer. The dead interval, D, corresponds to an interval within 

6 which a periodically transmitted neighbor packet is to be received over a particular link to 

7 indicate viability of that link. The time, x, basically represents the interval between reception 

8 of the neighbor packet and the prediction time, t, where x is an amount of time in the range of 

9 zero to the neighbor packet periodic transmission interval. The topology prediction function 
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1 subsequently notifies packet filter module 42 that a crosslink, downlink or uplink is about to 

2 become disabled within a subsequent interval. This interval is represented by D + T which is 

3 the sum of the OSPF dead interval, D, and a time, T, representing the maximum amount of 

4 time required for OSPF module 40 to recalculate a routing table after expiration of the dead 

5 interval. In other words, the topology prediction module informs the packet filter module of 

6 a disabled link at a time prior to link disablement sufficient to permit expiration of the dead 

7 interval (e.g., when the OSPF protocol considers the link disabled) and calculation of new 

8 routes. This enables new routes to be determined and utilized for current routes that become 

9 disabled due to the disabled link as described below. Packet filter module 42 proceeds to 

10 discard incoming and outgoing neighbor packets at time, t, for the link predicted to be 

1 1 disabled in response to notification from topology prediction module 38. 

12 The apriori knowledge relating to link disablement is typically stored in a look-up 

13 table accessible by the topology prediction module. The table generally includes information 

14 relating to satellite geographic position, time and link status (e.g., enabled or disabled). 

15 However, the look-up table may include any desired information. The information is 

16 generally provided for a predetermined time interval (e.g., two hours) corresponding to 

17 satellite orbits, and is repeatedly utilized for subsequent intervals. The topology prediction 

18 module accesses the look-up table information to predict disablement of links for route 

19 computation by the OSPF protocol as described below. 

20 When the dead interval timer for the predicted link expires at time, t - x + D (e.g., the 

21 sum of time, t - x, when a neighbor packet is received and dead interval, D) the OSPF module 

22 computes a new routing table in time interval, T, and transmits a link-state update message to 

23 neighboring network nodes (e.g., satellites and/or ground stations) to update corresponding 

24 databases. Thus, the OSPF module determines that a link is disabled within the dead interval, 

25 D, and disseminates this information throughout the network via the protocol link-state 

26 database exchange. The OSPF module completes the routing table calculations subsequent 

27 expiration of the dead interval at time, t - x + D + T (e.g., the sum of the expiration of the 

28 dead interval, t - x + D, and time, T, for computing the routing table) and sends the new 

29 routing table to IP module 36. The predicted link becomes disabled after computation of the 

30 routing table at time, t + D + T (e.g., the sum of the prediction time, t, dead interval, D, and 

31 computation time, T) and, at expiration of a subsequent dead interval, D, at time, t + 2D +T, 

32 the topology prediction module instructs the packet filter module to cease discarding the 

33 neighbor packets. This enables the OSPF module to receive neighbor packets over the link 
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1 from a neighboring router, thereby detecting viability of that link. The OSPF module further 

2 adjusts the routing tables accordingly. The additional dead interval, D, serves as a buffer to 

3 alleviate slight inaccuracies in predicted timing and to prevent detection of a link just prior to 

4 that link becoming disabled. In other words, the additional interval ensures that the interval 

5 when the link is actually disabled coincides with the utilization of alternative routes 

6 determined by the OSPF protocol. 

7 The present invention network was modeled using the OPNET simulation tool. Fig. 3 

8 illustrates the OPNET model representation of the exemplary network topology. 

9 Specifically, each satellite 10 is modeled as a router using a simulation tool node model. 

10 This node model is illustrated, by way of example, in Fig. 4. The node model basically 

1 1 simulates the protocol layers implemented in router 14 (Fig. 2) described above, and includes 

12 several modules that are described, by way of example only, in Table II below. The modules 

13 are typically implemented in software for execution by the simulation tool. 

Table II: Exemplary Router Node Modules 



Module Name 


; , i, Module Description 


addassign 


The add_assign module assigns the source and destination 
IP addresses to the traffic generated by the built in traffic 
generators or the traffic that is read in from a file. 


portman 


The port_man module passes the packets from the upper 
layer to the appropriate transport protocol (UDP or TCP) in 
the lower layer. This is done in both directions. 


udp 


The udp module implements the UDP protocol. 


tcp 


The tcp module implements the TCP protocol. 


ipencap 


The ip_encap module implements the part of the IP protocol 
that encapsulates packets received from the transport layer 
with the IP headers before sending them to the intranet layer. 
For packets received from the lower layer, the ip_encap 
module strips the IP headers from the packets and sends the 
packets to the transport layer. 
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Module Name 


Module Description 


»P 


The ip module implements the routing part of the IP 
protocol. 


route_maint 


The route maint module holds the routing table used by the 
IP protocol. 


icmp 


(Not used for the simulations.) 


LinkOutPred 


The LinkOutPred module is the Topology Prediction 
Function (TPF). 


ospfencap 


The ospf_encap module implements the encapsulation and 
de-encapsulation of the packets generated by the ospf_mod 
module. In addition, the ospf_encap module implements the 
Packet Filter. 


ospfmod 


The ospf_mod module implements the OSPF version 2 
(RFC 1583) adaptive routing protocol. 


EthSNDCF 


The Eth_SNDCF is the convergence function that maps the 
IP addresses to the Ethernet addresses. 


mac 


The mac module is the OPNET standard Ethernet Medium 
Access Control (MAC) layer. 


hub_txl 


The hub_txl module is the point-to-point transmitter from 
the Ethernet MAC layer to the Ethernet Hub. 


hubrxl 


The hub_rxl module is the point-to-point receiver from the 
Ethernet Hub to the Ethernet MAC layer. 


PPP_SNDCF_(2-7) 


The PPP_SNDCF_(2-7) are the convergence functions 
between IP and the Point-to-Point Protocol (PPP) links. 


Pp_xmit(2-7) 


The pp_xmit(2-7) modules are the point-to-point 
transmitters from one PPP_SNDCF module to another 
PPP_SNDCF module set to transmit packets at 20 Megabits 
per second (Mbps). 
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Module Name 


Module Description 


Pp_rcv(2-7) 


The pp_rcv(2-7) modules are the point-to-point receiver 
from one PPP_SNDCF module to another PPP_SNDCF 
module set to receive packets at 20 Megabits per second 
(Mbps). 


Cvs 


The cvs module is used by version control to keep track of 
the model version number. 



1 The simulated conditions included a dynamic scenario with a data traffic load, the 

2 OSPF protocol and links 18 intermittently enabled and disabled. This scenario was further 

3 employed without the data traffic load to determine the overhead associated with the present 

4 invention routing on the communication network. The values of OSPF parameters for the 

5 simulation were selected in order to verify the routing technique, and may not necessarily 

6 have optimal values. The interfaces implementing the OSPF protocol in the simulation were 

7 configured for point-to-point as opposed to broadcast transmissions. The various OSPF 

8 parameters and corresponding values utilized for the simulation are described, by way of 

9 example only, in Table III below. 
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Table III: Exemplary OSPF Parameters 



: OSPF Parameter 


Value 


: Description 


OSPF_ack_delay_ptp 


10.0 


Delay in seconds of an acknowledgement 
of a newly received link state 
advertisement. 


OSPF_LSRefreshTime 


200.0 


OSPF Link State Refresh timer in 
seconds. 


OSPF_startup_interval 


10.0 


Random startup interval for OSPF in 
seconds. 


Inf_Trans_Delay_ptp 


1.0 


The estimated number of seconds it takes 
to transmit a Link State Update Packet 
over this interface. 


Retrans_interval_ptp 


1.0 


OSPF Retransmit Interval for point-to- 
point links in seconds. 


Hello_interval_ptp 


2.5 


OSPF Hello Interval for point-to-point 
links in seconds. 


Dead_interval_ptp 


5.0 


OSPF Dead Interval for point-to-point 
links in seconds. 



1 Each satellite 10 within the simulation scenario transmitted a set of messages to other 

2 satellites within the network. The source and destination of each message were uniformly 

3 distributed among the network satellites. The message storage capacity was approximately 

4 five-hundred bytes, while the messages were transmitted in accordance with the User 

5 Datagram Protocol (UDP). The message load for each satellite was approximately twenty- 

6 four messages per minute. An approximate forty byte acknowledgement was transmitted by 

7 a satellite application layer in response to each successfully received message. The simulated 

8 load is sufficient to verify operation of the network routing for successful completion of all 

9 messages. 

10 The simulation scenario controlled crosslinks 16, 18 to simulate satellite movement. 

11 In particular, crosslinks 16 were enabled during the simulation, while crosslinks 18 were 
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controlled (e.g., enabled and disabled) as a function of simulated time. The network 
connectivity as a function of time is described, by way of example only, in Table IV below. 



Table IV: Network Connectivity Matrix 



Time (sec) 


01-09 


01-18 


0442 


04-21 


05-13 


05-22 


08-25 


09rl7 


13-21 


17-25 


0.0 


1 


1 


0 


0 


1 


1 


0 






0 


595.0 


1 


1 


0 


1 


1 


1 


0 






1 


600.0 


1 


0 


0 


1 


1 


0 


0 






1 


1195.0 


1 


0 


1 


1 


1 


0 


1 






1 


1200.0 


0 


0 


1 


1 


0 


0 


1 






1 



The top row of the table indicates time and link identifiers. For example, the link identifier 
"01 - 09" indicates the link between satellites DM and 1P_9 of Fig. 3 described above. The 
initial table column indicates the simulation time, while the table entries specify the status 
(e.g., enabled or disabled) of the link associated with the corresponding link identifier at the 
indicated simulation time (e.g., a '1' indicates link enablement, while a '0' indicates that the 
link is disabled). 

The topology prediction function was configured in the simulation to inhibit neighbor 
packets via the packet filter approximately six seconds prior to a crosslink 18 becoming 
disabled. The packet filter discarded these packets until instructed to cease this activity by 
the topology prediction function approximately five seconds after the link became disabled. 
The six second interval represents the sum of a dead interval, D, of five seconds and an 
interval, T, of one second for computation of routes as described above. An example of this 
interaction is illustrated in Table V below. 



TableV: TPF Dynamics 



Time (sec) 


Node Name 


Stream 


Switch 








WD 


594.0 


IP 1 


5 


0 


594.0 


IP 18 


5 


0 


594.0 


IP 5 


5 


0 


594.0 


IP 22 


5 


0 


605.0 


IP 1 


5 


1 


605.0 


IP 18 


5 


1 


605.0 


IP 5 


5 


1 


605.0 


IP 22 


5 


1 


1194.0 


IP 1 


4 


0 


1194.0 


IP 9 


4 


0 


1194.0 


IP 5 


4 


0 


1194.0 


IP 13 


4 


0 


1205.0 


IP 1 


4 


1 


1205.0 


IP 9 


4 


1 


1205.0 


IP 5 
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1 Specifically, the table indicates that the link (e.g., connected at IP stream five) between 

2 satellites IP_1 and IP_18 (Fig. 3) is predicted to become disabled. This prediction is 

3 determined at time, 594.0 seconds, thereby indicating that the link becomes disabled at the 

4 sum of the prediction time (e.g., 594.0 seconds), dead interval (e.g., five seconds) and 

5 computation interval (e.g., one second) as described above or at time, 600.0 seconds (Table 

6 IY). The topology prediction function waits for expiration of a subsequent dead interval 

7 (e.g., the sum of 600.0 seconds and a dead interval of five seconds) or until time, 605.0 

8 seconds, to instruct the packet filters of satellites IP l and IP_18 to cease discarding the 

9 neighbor packets (e.g., a "0" in the switch column for satellites FP_1 and 1P_18 at time, 594.0 

1 0 seconds, indicates reception and transmission of packets, while a ' 1 ' in the switch column for 

11 these satellites at time, 605.0 seconds, indicates discard of packets just prior to receiving 

12 instructions to cease that activity). 

13 The simulation results provided overhead information of the present invention routing 

14 on the communication network. The load information from the simulation is graphically 

15 illustrated in Figs. 5 A- 5C. These figures basically illustrate a plot of OSPF traffic load on 

16 crosslinks between satellites IP_1 and FP_18 (e.g., indicated as 01 - 18), between satellites 

17 IP_17 and IP_25 (e.g., indicated as 17 - 25) and between satellites EP25 and EP1 (e.g., 

18 indicated as 25-01) of the communication network. Link 25 - 01 represents a crosslink 16 

19 within the ring topology, while links 01-18 and 17-25 represent links 18 among satellites 

20 within a line of sight. Table IV indicates that crosslink 17 - 25 is enabled at time, 595.0 

21 seconds, while crosslink 01-18 becomes disabled at time, 600.0 seconds. This is verified in 

22 Figs. 5A and 5B by the lack of throughput during link disablement. Since link 25 - 01 is a 

23 ring topology link, the link remains enabled and provides throughput during the simulation as 

24 illustrated in Fig. 5 C. 

25 The throughput indicated in Figs. 5A - 5C is determined in accordance with a ten 

26 second window and is computed at time, t seconds, as follows: 

27 Throughputs Y^Y, S n (t) 

28 where At is the window duration (e.g., set to ten seconds), N(t) is the quantity of messages in 

29 a window at t seconds and S n (t) is the storage capacity (e.g., in bits) of the n th message in a 

30 window at t seconds. 

3 1 The plots indicate the throughput at a single side of a duplex link. For example, Fig. 

32 5 A illustrates the OSPF throughput from satellite IP_1 to satellite IP_18, while Fig. 5B 
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1 indicates the OSPF throughput from satellite IP_17 to satellite EP 25. Fig. 5C indicates the 

2 OSPF throughput from satellite IP_25 to satellite TP1 . The maximum throughput indicated 

3 on the plots is approximately three thousand bits per second (bps) which is approximately 

4 0.015% of the available bandwidth of a twenty million bits per second (bps) crosslink as 

5 shown below. 

6 Percentage of Overhead Bandwidth = 100 X 3,000 bps/20,000,000 bps = 0.015% 

7 The simulation results indicated that when the topology prediction function was 



8 enabled, the network achieved total message completion. Thus, the present invention routing 

9 operated to reroute messages to new routes prior to links becoming disabled, thereby 

10 preventing the IP protocol from routing packets to disabled links. When the topology 

11 prediction function was disabled, the network suffered packet loss with an approximate 

12 ninety-eight percent message completion rate. The messages were lost due to the IP protocol 

13 routing packets to disabled links prior to the OSPF protocol detecting the disabled link, via 

14 the conventional dead interval timer, and updating the IP routing table. 



15 The OSPF or other routing protocol combined with the topology prediction and 

16 packet filter of the present invention provides a routing mechanism that adequately 

17 accommodates the dynamic nature of a system. The present invention takes advantage of 

18 apriori knowledge of network topology as a function of time or satellite geographical location 

19 to enhance routing performance. The routing performance was verified via analysis of event 

20 timing and a simulation tool. The simulation indicated that the OSPF overhead on the 

21 network in a dynamic scenario is significantly less (e.g., a small percentage) than the 

22 available bandwidth, and that the present invention routing prevents the IP protocol from 

23 routing packets to disabled interfaces during system operation (e.g., without system failures). 

24 If system failures occur, the present invention routes packets around the failures via the OSPF 

25 protocol. This results in enhanced routing that combines the OSPF protocol with 

26 functionality that takes advantage of available and known network topology information. 

27 It will be appreciated that the embodiments described above and illustrated in the 

28 drawings represent only a few of the many ways of implementing a method and apparatus for 

29 routing information in satellite communication networks. 

30 The network may be implemented by any type of network where down time or 

31 topology changes may be predicted. The network may include any quantity of any 

32 conventional or other satellites (e.g., low orbiting, etc.), ground stations or other network 

33 nodes arranged in any desired fashion and at any locations. The satellites and ground stations 
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1 may include any quantity of any types of links (e.g., uplinks, downlinks, crosslinks, etc.) to 

2 facilitate communications. The links may employ any suitable communications medium 

3 (e.g., radio or other signal energy of any desired frequency, various transmission media, etc.). 

4 The present invention may be applied to any conventional or other routing protocols that 

5 perform probing (e.g., determine topology and viability of links). 

6 The router of the present invention may be of any quantity, and may be implemented 

7 by any conventional or other routing device or unit. The routers may communicate via the 

8 various links by any communications medium (e.g., radio or other energy signals of the same 

9 or different frequency). The router may employ any suitable routing protocol (e.g., OSPF, 

10 link-state, distance vector, etc.). The present invention may utilize any desired information or 

1 1 knowledge concerning network topology where the information may be based on any suitable 

12 criteria (e.g., time, position, etc.). The routing database and routing table may be 
iU 13 implemented by any quantity of any conventional or other storage structures (e.g., database, 
: 14 table, file, record, array, data structure, etc.). The look-up table for storing the apriori 
fU 15 knowledge may be implemented by any quantity of conventional or other storage structures 

= 16 (e.g., database, table, file, record, array, data structure, etc.). 

17 The router modules may be implemented in software or hardware, or any 

=. 1 8 combinations thereof. The router modules may be arranged in any fashion, while software 

u 

=11 19 implemented modules may be implemented in any computing language. The router may 

20 include any quantity of any conventional or other processor (e.g., microprocessor, controller, 

□ 21 etc.) or circuitry to execute software implemented modules and/or realize hardware modules. 

22 The functions of the router modules may be distributed in any manner among any quantity of 

23 software and/or hardware modules within or external of the router. For example, a separate 

24 unit in communication with the router may be employed to implement the topology 

25 prediction and filtering functions. It is to be understood that one of ordinary skill in the 

26 computer arts could develop the software implemented modules of the present invention 

27 based on the drawings, tables and functional descriptions contained herein. Further, the 

28 present invention routing and various router or module functions may be modified in any 

29 fashion to attain the functions described herein. 

30 The router may include any quantity of any type of applications (e.g., satellite, router, 

31 ground station, protocols, etc.) or application modules, and any quantity of any type of 

32 transport protocols (e.g., TCP, UDP, etc.). The router may include any quantity of ports for 

33 any quantity or type of communications or other devices (e.g., receiver, transmitter, 
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1 transceiver, etc.). The transceivers may be implemented by any quantity of conventional or 

2 other transceivers or combinations of receivers and transmitters, and may encrypt, modulate, 

3 transmit and/or receive information in any desired fashion. 

4 The topology prediction function may utilize any desired information or knowledge to 



5 predict disablement of links (e.g., geographic position, time, orbit, etc.). The various times or 

6 time intervals indicated above (e.g., prediction, dead interval, computation time, etc.) may be 

7 set or utilized in any desired units or portions thereof (e.g., hours, minutes, seconds, 

8 microseconds, nanoseconds, etc.). These times or intervals may be set to any desired values 

9 sufficient to conduct the routing. The time line for the routing may be modified in any 

10 desired fashion that accommodates the routing function described herein. The various timers 

1 1 (e.g., dead interval timer) may be implemented by any quantity of conventional or other 

12 timers, and may be implemented by software and/or hardware modules, or any combinations 

1 3 thereof. 

14 The look up table or other storage structure storing the prediction knowledge may 

15 include any desired information for any desired time interval (e.g., hours, days, months, etc.). 

16 The topology prediction function may notify the packet filter to discard and accept packets 

17 via any suitable notification scheme (e.g., messages, interrupts, etc.). The interval between 

1 8 link disablement and enabling the packet filter to accept packets may be set to any desired 

19 interval (e.g., dead interval or any other desired time interval) to compensate for possible 

20 timing inconsistencies. 



21 The packet filter may identify and discard packets based on any desired information 

22 (e.g., packet header information, information within packet data, etc.). The packet filter may 

23 discard and accept packets for any quantity of links. The packets transmitted by the network 

24 may be of any type, format or size. 

25 The simulation may be performed via any conventional or other simulation tool. The 



26 simulation may be performed utilizing any scenarios (e.g., topology changing), models, 

27 routing or other parameters, loads (e.g., messages per time interval) and/or distribution of 

28 source and destinations among nodes. The simulated or actual throughput may be measured 

29 based on any desired window of any duration. The simulation may be performed with 

30 messages and/or acknowledgments of any type, format or size, and/or with any desired 

31 protocols (e.g., OSPF, UDP, etc.). 

32 It is to be understood that the present invention is not limited to the applications 

33 disclosed herein, but may be applied to various communication networks and protocols to 
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1 enhance routing. Further, the present invention may establish any suitable conditions (e.g., 

2 cease transmission and reception of certain packets, cause expiration of timers, etc.) within 

3 the network to cause a routing protocol to recompute routes in order to accommodate 

4 disablement of links due to topology changes or other network conditions. 

5 From the foregoing description, it will be appreciated that the invention makes 

6 available a novel method and apparatus for routing information in satellite communication 

7 networks, wherein link disablement is predicted based on known topology information and 

8 conditions are established that cause a routing protocol to determine alternative routes prior 

9 to disablement of the links. 

10 Having described preferred embodiments of a new and improved method and 

11 apparatus for routing information in satellite communication networks, it is believed that 

12 other modifications, variations and changes will be suggested to those skilled in the art in 

13 view of the teachings set forth herein. It is therefore to be understood that all such variations, 

14 modifications and changes are believed to fall within the scope of the present invention as 

15 defined by the appended claims. 
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